In this article I want to share some of the things I've learned about creating successful shareware adventure games. Some of these things I've learned from countless hours of watching people play-testing my games. Other things I've learned from talking to people online, or from the letters I've received from gamers around the world. And some is just personal observation.
Common Commands
I've noticed that a lot of shareware adventures suffer from variations in the commands that the player uses to play the game. Commands should be consistent not only within an individual game, but should also be consistent with the commands used in similar adventure games. This is especially true of World Builder games, where there is already a basic similarity of form and function.
Although this may not apply to every possible game, in most cases certain command conventions should be adhered to. Otherwise you risk confusing and frustrating your players.
For instance, in my early games I tried using the word "INFO" as a command for talking to non-player characters. But during testing I found that most players would enter the word "TALK" when they wanted to talk to another character. This happened even when I had instructions at the beginning of the game informing people of the "INFO" command. People either overlooked it, or forgot it. And since you are trying to talk to a character, "TALK" was the command people naturally attempted.
In some games I've reviewed, the author has used keywords to trigger interaction between characters. The idea behind this is that the player will try to find out about certain plot elements, and will use those words. For instance, if the player has been told about a wizard who has something the player needs, the author expects the player to enter something like, "Ask about wizard" when he meets a bartender or other character. So the code is programmed to respond to the word "wizard."
The trouble with this is, the player often doesn't enter the right word or words. Perhaps the player doesn't know that this is how the conversation is supposed to be initiated. Or maybe the player asks for information using a different word or variation of the correct word. And again, in my experience the average player usually will enter something more like, "Talk to bartender."
So obviously "TALK" should be the standard command for initiating conversations, at least in World Builder games. If you wish, you can also include alternate words, such as INFO or ASK, all in the same line of code. Here's an example of a conversation in World Builder, taken from my game, "A Mess O'Trouble":
PRINT{USUR: "There is a magic sludgepit to the WEST. The elves have been dumping old magic potions, brews and elexirs there for centuries."}
PRINT{"In fact, this enchanted forest is the result of contamination from all that magic toxic waste!"}
LET{W8#=1}
EXIT
IF{W8#=1}THEN
PRINT{USUR: "In the Old Days, the elves used magic pellets to power many of their wondrous devices. But now even the elves don't remember how to make them."}
PRINT{"There are only a few left. I've got some, just a few that I've picked up in the forest over the years. About two bags full."}
LET{W8#=2}
EXIT
IF{W8#=2}THEN
PRINT{USUR: "You should always say the magic word when you see the symbol of a rocket."}
LET{W8#=3}
EXIT
IF{W8#=3}THEN
PRINT{USUR: "My cousin Smokey spent the winter with me last year and I darn near froze to death! Everytime I'd start a fire in the fireplace the idiot would pour water on it!"}
LET{W8#=4}
EXIT
IF{HAKO.BUTTON>STORAGE@}THEN
PRINT{USUR: "Well, I'm not supposed to tell you this, but there are 40 Maximum-Value Objects, not including the bonus items."}
EXIT
IF{HAKO.DOOR>STORAGE@}THEN
PRINT{USUR: "Here's a joke: What do you call a female tractor? A cowdozer!"}
EXIT
PRINT{USUR: "Sorry friend, I haven't heard anything new."}
EXIT
In this example the player can "talk" to the character (a bear named Usur) several times, and get more information. The variable W8 is used to keep track of which responses have already been given. Each time a response is given, the variable is updated. When the character can't give any additional information, a default response is printed: "Sorry friend, I haven't heard anything new."
A pair of additional IF/THEN statements allow for special responses later in the game.
Notice too that the character speaking is always identified, and his comments are always in quotation marks. This makes it easier for the player to tell that he has been spoken to, and by whom. This is a standard that I highly recommend.
----------------------------------------------
Using Objects
Here is another place where standardization is sorely needed. I've played games where the command needed to use an object is DROP, hardly the verb that most players would think of first! Other games, including my first game, tend to have different action verbs for different objects. This also leads to confusion for the player.
The simplest verb for handling actions is USE, and should be standard from game to game. And it allows you to program slightly more complex actions, where the player can USE one object with another. Here's an example:
IF{TEXT$=USE}OR{TEXT$=INSERT}OR{TEXT$=PUT}THEN
PRINT{........................................}
IF{TEXT$=MAGNET}THEN
IF{MAGNET>PLAYER@}THEN
PRINT{You don't have a magnet.}
EXIT
IF{M6#<1}THEN
PRINT{The electromagnet isn't powered.}
EXIT
IF{TEXT$=POT}OR{TEXT$=PLANT}OR{TEXT$=CAN}THEN
SOUND{CLINK}
SOUND{SLIDE.2}
MOVE{POT.1}TO{STORAGE@}
MOVE{POT.2}TO{STORAGE@}
MOVE{POT.3}TO{STORAGE@}
MOVE{POT.4}TO{STORAGE@}
MOVE{POT.5}TO{STORAGE@}
SOUND{PISTOL-COCKING.1}
MOVE{POT.6}TO{STORAGE@}
SOUND{PHAZE}
MOVE{GWDOOR.OPEN}TO{SCENE@}
PRINT{By putting the magnet against the glass, you drag the metal pot across the glass until it flips the switch, causing the glass door to open.}
PRINT{The wheel is on the far wall, too far away for the magnet to have any effect on it.}
EXIT
IF{TEXT$=DOOR}THEN
IF{GWDOOR.OPEN>SCENE@}THEN
PRINT{The glassy door is unaffected by the magnet.}
EXIT
PRINT{The door on the far wall is unaffected by the magnet.}
EXIT
PRINT{What do you want to use the magnet with?}
EXIT
IF{TEXT$=FORK}THEN
IF{FORK=PLAYER@}THEN
IF{GWDOOR.OPEN=SCENE@}THEN
MOVE{FORK}TO{STORAGE@}
MOVE{GFORK.1}TO{SCENE@}
SOUND{SNIP.2}
PRINT{The fork fits the socket perfectly, and becomes locked in place.}
EXIT
PRINT{The fork looks like it might fit the socket, but you can't reach the socket with the glass door closed.}
EXIT
PRINT{You don't have a fork.}
EXIT
IF{TEXT$=INSERT}THEN
PRINT{That doesn't fit in the socket.}
EXIT
END
This is a fairly complex example. There are several possible actions and variations that the player might try, and for every one of them there is an appropriate response.
The scene shows a room divided by an unbreakable glass wall. There is a glass door in the wall. On the other side of the glass, in the far wall, is another door, and beside it is a socket. On the floor near the glass is a lever, and a potted plant. The pot is made of iron or steel. To solve the puzzle, the player must use an electromagnet (taken from a nearby scene) to move the potted plant, tripping the lever which opens the glass door. Then the player must use a Data Fork in the socket, to open the inner door. For simplicity, the Data Fork object is just named "fork".
If the player enters USE and MAGNET, then the code checks to see if the player has the magnet. If he does, then the code checks to see if the player has specified what he wants to use the magnet with. If the player has entered either POT, PLANT or CAN, then the program performs the required action. If the player has entered the name of one of the other objects in the scene, then a response is printed telling the player that the magnet doesn't work with that particular object. If the player has only entered USE MAGNET, then the player is asked to be more specific: "What do you want to use the magnet with?"
Because some players might enter something like "PUT THE FORK IN THE SOCKET" or "INSERT THE FORK IN THE SOCKET," I've included the verbs PUT and INSERT as alternatives to USE.
Also, in my Global Code I have a default response for the verb USE. This response is printed any time the player attempts to use something unusual to solve a puzzle. For instance, if the player enters "USE SCREWDRIVER WITH SOCKET" the default response comes up: "That doesn't seem to work." This reduces the amount of code needed in each scene.
Default Responses
This brings up another point: Every common command used in the game should have some kind of default response to handle the times when the player tries to do something you didn't think of! Sure, World Builder has a default response "hard-wired" into it, but reading "Huh?" everytime you try to do something turns players off. In most cases there should be a response that tells the player that he can't do what he is attempting, or gives a reason why he can't do it.
Here are some of the Global default responses I use:
PRINT{The water in the canteen relieves your thirst.}
LET{H2#=90}
IF{W1#=0}THEN
PRINT{The canteen is now empty.}
EXIT
EXIT
PRINT{Your canteen is empty.}
EXIT
PRINT{Drink what?}
EXIT
IF{TEXT$=EAT}OR{TEXT$=TASTE}THEN
PRINT{..................................}
IF{TEXT$=FOOD}THEN
IF{FOOD=PLAYER@}THEN
SOUND{CHEWING.1}
SOUND{BELCH.2}
PRINT{The food is filling.}
LET{H1#=95}
MOVE{FOOD}TO{STORAGE@}
EXIT
PRINT{You don't have any food.}
EXIT
PRINT{Eat what?}
EXIT
IF{TEXT$=HELP}THEN
SOUND{SINISTER LAUGH}
PRINT{RAY: "Surely you jest! You're on your own here."}
EXIT
IF{TEXT$=READ}THEN
PRINT{..................................}
IF{TEXT$=MAP}THEN
IF{MAP=PLAYER@}THEN
MOVE{MAP.1}TO{SCENE@}
PRINT{To stop, click on the map.}
EXIT
PRINT{You don't have a map.}
EXIT
PRINT{Read what?}
EXIT
IF{TEXT$=SHOOT}THEN
PRINT{You can't shoot that.}
EXIT
IF{TEXT$=KILL SELF}OR{TEXT$=SUICIDE}THEN
PRINT{You can't get out of this that easily!}
EXIT
IF{TEXT$=HIT}OR{TEXT$=BREAK}THEN
PRINT{You can't break that.}
EXIT
All of these are things that players WILL try to do somewhere in almost every adventure game. All of the commands listed here are used by players often enough that they should be considered standard. And you may need others that apply to specific situations in your game.
Some default responses can be handled better in scene code, especially when it is something that applies only to a specific situation in a scene.
Also, although it isn't strictly necessary, I usually like to have a default response for those times when the player gets mad enough to swear at the game, or at a character in the game.
-------------------------------------------------
Standardizing Windows
Your scene and text windows should remain the same throughout your game, only changing size and/or shape when absolutely necessary. I've played a lot of games where the windows change size, or move around the screen, almost every time you enter a scene. This looks unprofessional, and is annoying to most players.
Also, in World Builder the windows are automatically set so that the text window is shorter than the scene window. This doesn't leave you much room for text, especially in scenes where the player is conversing with another character. To get the most from the text window, stretch it so that it is as tall as the scene window. Also, you can widen it a little too, and make the two windows touch. But don't overlap them! Once you have done this on the first scene, before adding any text or drawings, copy the entire room and then paste it as many times as needed for your game. This will insure that all your scenes are exactly the same size and position.
There is another reason for keeping your windows the same throughout the game. If the windows are always the same, it will take less time when the player moves from one scene to another.
Windows in "Ray's World Template"
In the special World Template I created, there is one blank scene. The windows in this scene have already been set to the optimum size and position. All you have to do is copy this blank scene and paste in as many copies of it as you need. This way all the windows will be the same throughout the game. If you need one or two scenes with special windows, you can adjust those scenes individually.
If you wanted to , you could make a game with larger windows, to take advantage of the larger screens that are common on most Macs these days. Bear in mind that if you do this, your game won't work properly on older Macs and PowerBooks, which have small screens. That would limit the number of downloads and registrations your game receives especially since WB games are ideally suited for use on small screen Macs.
